-
Notifications
You must be signed in to change notification settings - Fork 23
coot/ghc 8.10 fix #92
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
coot
commented
Apr 26, 2023
- io-classes: fixed building haddocks with ghc-8.10
- version 1.1.0.0
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
## Next version should be replaced by ## 1.1.0.0
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Fixed.
| mtl, | ||
|
|
||
| io-classes ^>= 1.0.0.0, | ||
| io-classes >= 1.0 && < 1.2, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There is no changelog entry for this change
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, because I will just add a revision on hackage, no need to bump its version.
| time >=1.9.1 && <1.13, | ||
|
|
||
| io-classes ^>=1.0 | ||
| io-classes >=1.0 && <1.2 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If this is the only change made to the package between 1.0.0.0 and 1.1.0.0, would a revision of 1.0.0.0 be sufficient? Or is it the goal to release the packages in lockstep with the same version for each package?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I do release io-classes, io-sim, strict-stm, strict-mvar and si-timers (but not io-classes-mtl) in lock step, but I am fine to be more relaxed with lower bounds when I am sure things will still work.
| TypeFamilies | ||
| build-depends: base >=4.9 && <4.19, | ||
| io-classes ^>=1.0, | ||
| io-classes ^>=1.1, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Would >= 1.0 && < 1.2 also suffice? I think building with 1.0 would cause some deprecation warnings to be emitted with respect to moving the MonadMVar module, but would it lead to actual build failures?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I did this because io-sim:test would fail to compile with io-classes-1.0.
| ## 1.1.0.0 | ||
|
|
||
| ### Non breaking changes | ||
|
|
||
| * `io-classes-1.1.0.0` | ||
|
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
jorisdral
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM